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Abstract. The category-theoretic concept of a monad occurs widely as 
a design pattern for functional programming with effects. The utility and 
ubiquity of monads is such that some languages provide syntactic sugar 
for this pattern, further encouraging its use. We argue that comonads, 
the dual of monads, similarly provide a useful design pattern, captur¬ 
ing notions of context dependence. However, comonads remain relatively 
under-used compared to monads—due to a lack of knowledge of the de¬ 
sign pattern along with the lack of accompanying simplifying syntax. 

We propose a lightweight syntax for comonads in Haskell, analogous to 
the do-notation for monads, and provide examples of its use. Via our 
notation, we also provide a tutorial on programming with comonads. 

Many algebraic approaches to programming apply concepts from category the¬ 
ory as design patterns for abstracting and structuring programs. For example, 
the category-theoretic notion of a monad is widely used to structure programs 
with side effects, encapsulating effects within a parametric data type [1,2]. A 
monadic data type M has accompanying operations which provide composition 
of functions with structured output of type a —> Mb. Side effects can be seen as 
impure output behaviour, encoded by the data type M. 

Monads are so effective as an abstraction technique that some languages 
provide a lightweight syntactic sugar simplifying programming with monads, 
such as the do-notation in Haskell and the let! notation in F# [3]. 

Comonads are the dual structure to monads, where a comonadic data type 
C has operations for the composition of functions with structured input, of type 
Ca->5. Whilst monads capture impure output behaviour (side effects), comon¬ 
ads capture impure input behaviour, often described as context dependence, en¬ 
coded by the data type C. There are various examples of programming with 
comonads in the literature including dataflow programming via streams [4], at¬ 
tribute evaluation [5], array computations [6], and more [7]. However, despite 
these examples, comonads are less widely used than monads. 

There are two reasons for this: one is that they are less well-known, the other, 
related reason is the lack of language support, which impedes the use of comon¬ 
ads as a design pattern. To remedy this, we propose a syntax which simplifies 
programming with comonads in Haskell, called the codo-notation , which also 
serves to promote the comonad design pattern. 

In Haskell, comonads are defined by the following class: 1 
1 Available via Edward Kmett’s Control. Comonad package. 





class Comonad c where 
extract: : c a —» a 
extend :: (c a —» b) —> c a —» c & 

The contextual view of comonads is that values of type c a encode context- 
dependent computations of values of type a, and functions c a —» 6 describe local 
operations within some context. The extract operation defines a notion of current 
context and is a trivial local operation returning the value at this context; extend 
defines the range of all possible contexts, extending a local operation to a global 
operation by applying it at every context. Thus comonads abstract “boilerplate” 
code for extending an operation, defined at one context, to all contexts. 

For example, arrays can be seen as encoding contextual computations, where 
a value depends on its position. An array paired with an array index denoting the 
current context - called the cursor - is a comonad. Its extract operation accesses 
the cursor element of the array; extend applies a local operation, which computes 
a value from an array at a particular cursor, to an array at each possible cursor 
index in its domain (i.e., globally), computing an array of results [6]. Local 
operations of this form, on arrays, are ubiquitous in image processing, scientific 
computing, and cellular automata. 

The codo-notation simplifies programming with comonads. For example, the 
following codo-block defines a local operation for computing image contours: 

contours :: CArray (Int , Int) Float —¥ Float 
contours = codo x => y <— gauss2D x 
z <- gauss2D y 
w <— (extract y) — (extract z ) 
laplace2D w 

where CArray i a is a cursored-array data type, with index type i and element 
type a, and gauss2D , laplace2D :: CArray (Int, Int) Float —> Float compute, 
at a particular index, discrete Gaussian and Laplace operators on 2D arrays. A 
contour image can thus be computed by applying ( extend contours) to an image. 

The primary contribution of this paper is the codo-notation, introduced in 
detail in Section 1, continuing with arrays as an example. The notation desug¬ 
ars into the operations of a comonad (Section 3) which provides an equational 
theory for the notation following from the laws of a comonad (Section 2). The 
codo-notation is analogous to the do-notation for programming with monads in 
Haskell, but with some notable differences which are explained from a categorical 
semantics perspective in Section 4. Section 5 discusses related work, including 
a comparison of the codo-notation to Haskell’s arrow notation. 

This paper contributes examples (arrays, trees, and graphs), explanation, 
and notation to promote comonads in programming. A prototype of the nota¬ 
tion, as a macro-based library using quasi-quoting brackets, is provided by the 
codo-notation package. 2 An implementation as a GHC extension is in progress. 

2 http://hackage.haskell.org/package/codo-notation 




Array example The array comonad is used throughout the next section to 
introduce codo. It is defined in Haskell by the following data type and instance: 

data CArray i a = CA (Array i a) i 
instance lx i => Comonad (CArray i) where 
extract (CA a i) = a \ i 

extend f (CA a i) = let es' = map (A j -f (j,f (CA a j ))) (indices a) 
in CA (array (bounds a) es') i 

where extract accesses the cursor element using the array indexing operation !, 
and, for every index j of the parameter array, extend applies / to the array with 
j as its cursor, returning an index-value pair list from which the result array 
is constructed. Note, the return and parameter arrays have the same size and 
cursor, i.e., extend preserves the incoming context in its result. 

Many array operations can be defined as local operations c a —> b (hereafter 
comonadic operations, sometimes called coKleisli arrows/morphisms in the lit¬ 
erature) using relative indexing, e.g., the laplace2D operator, for approximating 
differentiation, can be defined: 

laplace2D :: CArray (Int, Int) Float -> Float 

laplace2D a=a1 (-1, 0) + a ? (1, 0) + a ? (0, -1) + a ? (0, 1) - 4 * a ? (0,0) 
where (?) abstracts relative indexing with bounds checking and default values: 3 
(?):: (lx i, Num a, Num i) => CArray i a -r i —>• a 
(CA a i)2 i' = if (inRange (bounds a) (i + i')) then a ! (i + i') else 0 

(where lx is the class of valid array-index types). Whilst laplace2D computes the 
Laplacian at a single context (locally), extend laplace2D computes the Laplacian 
at every context (globally), returning an array rather than a single float. 

1 Introducing codo 

The codo-notation provides a form of Zef-binding for composing comonadic op¬ 
erations, which has the general form and type: 

(codo p => p e; e):: Comonad c => c t —» t' 

(where p ranges over patterns, e over expressions, and t, t! over types). Compare 
this with the general form and type of the monadic do-notation: 

(do j) e;c) :: Monad m => m t 

Both comprise zero or more binding statements of the form p <— e (separated 
by semicolons or new lines), preceding a final result expression. A codo-block 
however defines a function, with a pattern-match on its parameter following 
the codo keyword. The parameter is essential as comonads describe functions 
with structured input. A do-block is instead an expression (nullary function). 
Section 4 compares the two notations in detail. 

3 There are many alternative methods for abstracting boundary checking and values; 
our choice here is for simplicity of presentation rather than performance or accuracy. 



Comonads and codo-notation for composition The extend operation of a 
comonad provides composition for comonadic functions as follows: 

(6) :: Comonad c=>(cy—>z)—>(cx—>y)—>cx—>z 
g ° f = g o (extend f) (1) 

The laws of a comonad are equivalent to requiring that this composition is 
associative and that extract is its identity (discussed further in Section 2). 

The codo-notation abstracts over extend in the composition of comonadic 
operations. For example, the composition of two array operations: 

lapGauss = laplace2D o (extend gauss2D) 

(be., laplace2D 6 gauss2D), can be written equivalently in the codo-notation: 

lapGauss = codo x => y <r- gauss2D x 
laplace2D y 

where lapGauss:: CArray (Int, Int) Float — > Float, x, y:: CArray (Int, Int ) Float. 

The parameter of a codo-block provides the context of the whole block where 
all subsequent local variables have the same context. For example, x and y in 
the above example block are arrays of the same size with the same cursor. 

For a variable-pattern parameter, a codo-block is typed by the following rule: 
(here typing rules are presented with a single colon : for the typing relation) 

[varP ]_ r ' X:ct ^ e:t ' _ 

r b (codo x =>■ e) : Comonad c => ct -4 t' 

where b c types statements of a codo-block. Judgments F ; A b c ... have two 
sequences of variable-type assumptions: r for variables outside a block and A for 
variables local to a block. For example, variable-pattern statements are typed: 

. r-,A \- c e:t r-A.x-.ct^.v.t' 

[varB1 r-,A b c a; e; r : i' 

where r ranges over remaining statements and result expression be. r = p f - e\c'. 

A variable-pattern statement therefore locally binds a variable, in scope for 
the rest of the block. The typing, where e : t but x:ct, gives a hint about codo 
desugaring. Informally, (codo y => x «- e; e!) is desugared into two functions, 
the first statement as \y —> e and the result expression as Xx —> e'. These are 
comonadically composed, be., (Aa; -4 e') o (extend (A y -4 e)), thus x : ct. 
Further typing rules for the codo-notation are collected in Fig. 1. 

Non-linear plumbing For the lapGauss example, codo does not provide a 
significant simplification. The codo-notation more clearly benefits computations 
which are not mere linear function compositions. Consider a binary operation: 


minus :: (Comonad c, Num a) => < 
minus x y = extract x — extract y 





which subtracts its parameters at their respective current contexts. Using codo, 
minus can be used to compute a pointwise subtraction, e.g. 

contours' = codo x => y ■*— gauss2D x 
z gauss2D y 
w «— minus y z 
laplace2D w 

(equivalent to contours in the introduction which inlined the definition of minus). 
The context, and therefore cursor, of every variable in the block is the same as 
that of x. Thus, y and z have the same cursor and minus is applied pointwise. 
The equivalent program without codo is considerably more complex: 

contours' x = let y = extend gauss2D x 

w = extend (A y' — > let z = extend gauss2D y' 
in minus y' z) y 

in laplace2D w 

where the nested extend means that y' and z have the same cursor, thus minus y' z 
is pointwise. An alternate, more point-free, approach uses the composition 6: 

contours' = laplace2D 6 (A y’ — > minus y' 6 gauss2D $ y') 6 gauss2D 

This approach resembles that of using monads without the do-notation, and 
is elegant for simple, linear function composition. However, for more complex 
plumbing the approach quickly becomes cumbersome. In the above two (non- 
codo) examples, care is needed to ensure that minus is applied pointwise. An 
incorrect attempt to simplify the first non-codo contours' might be: 

contour-bad x = let y = extend gauss2D x 
z = extend gauss2D y 
w = extend (minus y) z 
in laplace2D w 





In the above, extend (minus y ) z subtracts z at every context from y at a par¬ 
ticular, fixed context, i.e., not a pointwise subtraction. An equivalent expression 
to contoursJbad can be written using nested codo-blocks: 

contour J>ad = codo x =>■ y gauss2D x 

(codo y' =>■ z gauss2D y' 

w minus y z 

laplace2D w) y 

where y in minus y z is bound in the outer codo-block and thus has its cursor 
fixed, whilst z is bound in the inner codo-block and has its cursor varying. Vari¬ 
ables bound outside of the nearest enclosing codo-block are “unsynchronised” 
with respect to the context inside the block, i.e., at a different context. 

A codo-block may have multiple parameters in an uncurried-style, via tuple 
patterns ([tupP], Fig. 1). For example, the following block has two parameters, 
which are Laplace-transformed and then pointwise added: 

lapPlus :: CArray Int (Float, Float) —> Float 
lapPlus = codo (x, y) =>■ a 4— laplace2D x 
b <- laplace2D y 
(extract a) + (extract b) 

This block has a single comonadic parameter with tuple elements, whose type 
is of the form c (a, b). However, inside the block x : c a and y : c b as the 
desugaring of codo unzips the parameter (see Section 3). A comonadic tuple 
parameter ensures that multiple parameters have the same context, e.g., x and y 
in the above example have the same shape/cursor. Therefore, a pair of arguments 
to lapPlus must be zipped first, provided by the czip operation: 

class ComonadZip c where czip :: (c a, c b) —> c (a, b) 

For CArray, czip can be defined: 

instance (Eq i, lx i) => ComonadZip (CArray i ) where 
czip (CA a i, CA a' j) = 

if (i jk j V bounds a ^ bounds a') then error "Shape/cursor mismatch" 
else let es" = map (Xk —¥ ( k, (a ! k, a '! k))) (indices a) 
in CA (array (bounds a) es") i 

Thus only arrays of the same shape and cursor can be zipped together. In the 
contextual understanding, the two parameter arrays are thus synchronised in 
their contexts. The example of lapPlus can be applied to two (synchronised) 
array parameters x and y by extend lapPlus (czip (x, y)). 

Any data constructor pattern can be used for the parameter of a codo-block 
and on the left-hand side of a binding statement. For example, the following uses 
a tuple pattern in a binding statement (see [tupB], Fig. 1), which is equivalent 
to lapPlus by exchanging a parameter binding with a statement binding: 



lapPlus = codo 2 => (x, y) 4- extract z 
a 4- laplace2D x 
b 4- laplace2D y 
(extract a) + (extract b) 

Tuple patterns are specifically discussed here since they provide multiple pa¬ 
rameters to a codo-block, as seen above. The typing of a general pattern in a 
statement, for some type/data constructor T, is roughly as follows: 

.T; A\- c e : Tt E\ A, A' r : t' dom(A') = var-pats(p) 

[patB| - r-,AK (Tp)e; r : ('- 

where dom(A') is the set of variables in a sequence of typing assumptions, and 
var-pats is the set of variables occurring in a pattern. 

Example: labelled graphs Many graph algorithms can be structured by a 
comonad, particularly compiler analyses and transformations on control flow 
graphs (CFGs). The following defines a labelled-graph comonad as a (non-empty) 
list of nodes which are pairs of a label and a list of their connected vertices: 

data LGraph a = LG [(a, [Int} )] Int — pre-condition: non-empty lists 
instance Comonad LGraph where 
extract (LG xs c ) = fst (xs !! c) 

extend f (LG xs c) = LG (map (Ac' —> (f (LG xs c'), snd (xs !! c'))) 

[0.. length xs]) c 

The LGraph-comon&d resembles the array comonad where contexts are posi¬ 
tions with a cursor denoting the current position. Analyses over CFGs can be 
defined using graphs labelled by syntax trees. For example, a live-variable anal¬ 
ysis (which, for an imperative language, calculates the set of variables that may 
be used in a block before being (re)defined) can be written, using codo, as: 

Iva = codo g => IvO (defUse g, []) — compute definition/use sets, paired 

Iva' IvO — with initial empty live-variable set 

Iva' = codo (( def, use), Iv) =>■ 

live-out 4— foldl union [] (successors Iv) 

liveJn 4- union (extract def) ((extract live^out) \\ (extract use)) 
Ivp 4- ((extract def, extract use), extract live-in) 

IvNext 4— Iva' Ivp 

if (Iv = live-in) then (extract Iv) else (extract IvNext) 

where union and set difference (\\) on lists have type Eq a => [a] -4 [a] [a] 

and defUse :: LGraph AST —> ([ Var], [ Var]) computes the sets of variables 
defined and used by each block in a CFG. The analysis is recursive, refining the 
set of live variables until a fixed point is reached. 

The live variables for every block of a CFG can be computed by extend Iva. 




Costate, trees, and zippers Arrays were used to introduce comonads and 
codo to aid understanding since the notion of context is made clear by the 
cursor. The above graph example has a similar form. Both are instances of a 
general comonad, often called the costate comonad, whose data type is a pair of 
a function from contexts to values and a particular context: C a = (s —> a) x s. 

For both arrays and labelled graphs, the type of contexts is a finite domain 
of integer, or integer-tuple, indices. For labelled graphs, the costate comonad is 
combined with product comonad (see [8]) pairing the label of a node with the 
list of its successors, thus the type is isomorphic to C a = (s -» (a x [«])) x s. 

For costate, the notion of context is explicitly provided by a cursor acting 
as a pointer or address. This is not the only way to define a notion of context. 
Other data types encode the context structurally rather than using a cursor. For 
example, a comonad of labelled binary trees can be defined: 

data BTree a = Leaf a \ Node a (BTree a) (BTree a) 
instance Comonad BTree where 
extract (Leaf a) = a 
extract (Node a l r) = a 
extend f (Leaf a) = Leaf (f (Leaf a)) 

extend f t@(Node a l r) = Node (f t) (extend f l) (extend f r) 

The action of extend is to apply its parameter function / to successive suffix 
trees, thus / can only access its children, not its parents. Thus extend not only 
defines what it means for a local (comonadic) operation to be applied globally, 
but also which contexts are accessible from each possible context. 

A tree comonad that has a structural notion of context but whose comonadic 
operations can access any part of the tree can be defined using Huet’s zipper data 
type, where trees are split into a path to the current position and the remaining 
parts of the tree [9,5]. For a certain class of data types it has been shown that a 
zipper structure can be automatically derived by differentiation of the data type 
[10]. All container-like zippers are comonads [11] where the notion of context is 
encoded structurally, rather than by a pointer- like cursor. The codo-notation 
thus provides a convenient syntax for programming with zipper comonads. 

2 Equational Theory 

As shown in Section 1, extend provides composition for comonadic functions, 
Eq. (1). The laws of a comonad are exactly the laws that guarantee this compo¬ 
sition is associative with extract as a left and right unit, i.e. 


(right unit) 

/ 6 extract = f ~ 

-> extend extract = id 

[Cl] 

(left unit) 

extract 6 / = / ~- 

* extract o (extend /) = / 

[C2] 

(associativity) 

h 6 (g 6 /) 

+ extend g o extend f 



= (h 6 g) 6 / 

= extend (g o extend f) 

[C3] 


As there is no mechanism for enforcing such rules in Haskell the programmer is 
expected to verify the laws themselves. 



Since codo is desugared into the operations of a comonad, the comonad laws 
imply equational laws for the codo-notation, shown in Fig. 2(a). Fig. 2(b) shows 
additional codo laws which follow from the desugaring. 

Comonads are functors The category theoretic notion of a functor can be 
used to abstract map-like operations on parametric data types. In Haskell, func¬ 
tors are described by the Functor type class, of which map provides the list 
instance: 

class Functor f where fmap :: (a —» b) —» f a —» / b 
instance Functor [ ] where fmap = map 

All comonads are functors by the following definition using extend and extract: 

cmap :: Comonad c => (a —>b)^ca—>cb 
cmap f x = extend (/ o extract) 

While fmap applies its parameter function to a single element of a data type, 
extend applies its parameter function to a subset (possibly the whole) of the 
parameter structure. Thus extend generalises fmap. 

Monoidal operation The czip :: (c a, c b) —> c (a, b) operation introduced in 
Section 1 corresponds to that of a (semi)-monoidal functor which may satisfy 
various laws with respect to the comonad (see the discussion of (semi)-monoidal 
comonads in [8]). The following property, which we call idempotency of a semi- 
monoidal functor, frequently holds of comonad/ czip implementations: 

czip (x, x) = cmap (A y (y, y)) x (2) 

This property implies codo laws relating tuple patterns and czip (Fig. 2(c)). For 
every rule involving a tuple pattern there is an equivalent rule derived using the 
(x) rule (Fig. 2(b)) which exchanges parameter and statement binders. 

Shape preservation The shape of a data structure is defined by its structure 
without any values, which can be computed as such: (where const x = A_ — > x) 

shape = cmap (const ()) 

An interesting derived property of comonads is that, for any comonadic function 
/, (extend f) preserves the shape of the incoming structure in its result. For 
example, extend of the array comonad preserves the size, cursor, and dimensions 
of the parameter array in the result. Appendix A gives a proof of this property, 
which is stated formally, for a comonad c and function / :: c a —> b, as: 

shape o (extend f) = shape (3) 

This property explains why all locally bound variables in a codo-block bind 
comonadic values which have the same context. 



(a) Comonad laws 


(b) Pure laws 


[Cl] codo x => f x 
-£ codo x => y 4— extract x 

f V 

[C2] codo x^fx 
M codo x => y 4— f x 
extract y 

[C3] (iff x is not free in ei) 
codo x => y 4— ei 
z 4- e 2 

codo x' => z <— (codo x => y 4— ei 
e 2 ) a' 
e 3 

S codo x' => y <— e 1 

(codo a: => 2 4— e 2 
e 3 ) # 

Fig. 2. Equational la’ 


(»?) codo a :=>fx=f 

(/?) codo a: => 2 4— (codo y => ei) x 
e 2 

p codo x => y 4— extract x 
z <- e i 
e 2 

(x) codo p => e 
= codo z => p extract z 

(c) Additional laws - if Eq. (2) holds 
codo x => f a b 

= codo x (o', &') 4- extract (czip (a, b)) 
fa' b' 

codo (b, c) =>■ / (ozip (6, c)) 

= codo (b, c) =>■ 2 4— (extract b, extract c) 

fz 

s for the codo-notation 


3 Desugaring codo 

The desugaring of codo is based on Uustalu and Vene’s semantics for a context- 
dependent A-calculus [8]. It has two parts: translation of statements into com¬ 
position via extend, and management of the environment for variables bound 
in a codo-block. The first part is explained by considering a restricted codo- 
notation, which only ever has one local variable, bound in the previous statement. 

1) . Single-variable environment For a comonad C, consider the codo-block: 

fool = (codo a; => ?/ 4— f x\ g y) :: C x -» z 

where / :: C x —» y, g :: C y —> z. The first statement y 4— / x can be desugared 
as a function with parameter x and body f x, the second, which is the final result 
expression, can be similarly desugared as a function from y to its expression, £ e. 
(Ax —¥ f x) and (A y —tgy)- Both are functions with structured input, thus the 
semantics of fool is their comonadic composition (equivalent to go /): 

[[/oof] = (A y —> g y) o ( extend (Ax f x)) :: Cx —> z. 

2) . Multiple-variable environment A codo-block may bind multiple variables, 
allowing the following example with binary function h :: Cx Cy z: 

foo2 = (codo a; => ?/ 4— f x\ h x y) :: C x -» z 



The first statement cannot be desugared as before since the second statement 
uses both x and y, thus the desugaring must return x with the result of / x: 

(Xx —> (extract x,f x )) (x, y) (#4) 

Applying extract to x means that extend (#4), of type C x -> C (x,y), returns 
the parameter x and the result of f x synchronised in their contexts. 

The desugaring of the second statement is a function taking a value C ( x , y) 
and unzipping it, binding the constituent values to x and y in the scope of the 
result expression, where x and y are synchronised at the same context since 
cmap preserves the context encoded by the comonadic value: 

(A env —> let x = cmap fst env 

y = cmap snd env in h x y) :: C (x, y) —>■ z (#5) 

The desugaring of foo2 is therefore [/ooil] = (#5) o ( extend (#4)). 

3.1 General construction 

The desugaring translation traverses the list of binding statements in a codo- 
block, accumulating a comonadic environment of the local variables bound so 
far. The accumulated environment is structured by right-nested pairs terminated 
by a unit value (). Thus, the actual desugaring of foo2 is: 

l/boD] = (A env —>• let y = cmap fst env 

x = cmap (fst o snd) env in h x y) 
o (extend (A env —» (let x = cmap fst env in f x, extract env))) 
o (cmap (A env (env, ()))) 

For foo2, the environment in the first statement contains just x and has type 
C (x, ()), and in the second statement contains x and y and has type C (y, (x, ())). 
The top-level translation of a codo-block is defined: 

[codo x => 6] = [x h 6] c o (cmap (Ax —a? (x, ()))) 

[codo _ => &] = [[- I— 6] c o (cmap (Ax —¥ (x, ()))) 

[codo (x, y) => 6] = [a;, y b 6] c ° cmap (Ap —> (fst p, (snd p, ()))) 

where [A b 6] c is the translation of the binding statements b within a codo- 
block, with the scope of the local variables A. In the translation here, types are 
omitted for brevity. A translation with the types included can be found in the 
first author’s forthcoming PhD dissertation [12]. 

The top-level translation generalises easily to arbitrary patterns. In each case, 
[—] c is pre-composed with a lifted projection function, which projects values 
inside the incoming parameter comonad to right-nested pairs terminated by (). 
The translation of binding statements yields a Haskell function of type: 


[A I- b ; e] c : Comonad c => c (ti, (..., (t n , ()))) —> t 



where e : t and A = Vi,... ,v n where i>* : c t,. The definition of J—] c is: 

[Zl h e] c = [/i I- ej exp 

\A h x<—e; r] c = [x, A h r] c o extend (Xenv—> ([[4 h e} exp env, extract env)) 
\A \~ (x, y)-^e; r] c = \x,y,A\- r] c o extend (Aenv-> (A((x, y),A)->(x, ( y,A ))) 
(|Z\ h e]exp env, extract env)) 

where [Z\ h e] exp translates expressions on the right-hand side of a statement or 
for the result of a block. The last case translates tuple-pattern statements where 
A((x,y), A) —> (x,(y,A))) reformats results into the right-nested tuple format 
of the environment; this generalises in the obvious way to arbitrary patterns. 

The translation of expressions unzips the incoming comonadic environment, 
binding the values to the variables in A with a local ZeZ-binding: 

[«i, ... ,v n \~ e] exp = A env —> let [v* = cmap (fst o snd % ~ 1 ) env]" in e 

where snd k means k compositions of snd and snd° = id. 

The next section compares codo-notation with do-notation, and explains 
why the desugaring of codo-notation is more complex. 

4 Comparing do- and codo-notation 

Whilst comonads and monads are dual, this duality does not appear to extend 
to the codo- and do-notation. Both provide ZeZ-binding syntax, for composition 
of comonadic and monadic operations respectively. However, codo-blocks are 
parameterised, of type c a b for a comonad c, whilst do-blocks are unpa- 
rameterised, of type m a for a monad m. Since comonads abstract functions 
with structured input, the parameter to a codo-block is important. In the do- 
notation, expressions have implicit input via their free variables and Haskell’s 
scoping mechanism is reused for handling local variables in a do-block. 

The codo- and do-notation can be seen as internal domain-specific lan¬ 
guages, for contextual and effectful computations respectively, with their seman¬ 
tics defined by translation to Haskell. This perspective is similar to the approach 
of categorical semantics , where typed programs are given a denotation as a mor¬ 
phism 4 in some category, mapping from the inputs of a program to the outputs. 
The disparity between codo- and do-notation is illuminated by this approach. 

Categorical semantics For the simply-typed A-calculus, the traditional ap¬ 
proach recursively maps the type derivation of an expression to a morphism [13]: 

[-T I- e : t] : (pi] x ... x [f„]) —> | [tj 

where T = x± : ti,... x n : t n . Thus, an expression e : t with the free-variable 
typing assumptions T is modelled as a morphism from a product of the types 
for the free variables, as inputs, to the result type as the output. 

4 Morphisms generalise the notion of function. Readers unfamiliar with category the¬ 
ory may safely replace ‘morphism’ with ‘function’ here. 





Categorical semantics for effectful computations Moggi showed that ef¬ 
fectful computations can be given a semantics in terms of a Kleisli category [14, 
15], which has morphisms a —> m b for a monad to, with denotations: 

1*1 :ti,...x n : t n r e : : ([ti] X ... X [t n ]) —f to ft} 

In Moggi’s calculus, Zef-binding corresponds to a call-by-value (eager) evaluation 
of effects followed by substitution of a pure value, corresponding to composition 
of the denotations provided by the bind operation of a monad. The semantics 
of multi-variable environments requires a strong monad: a monad with an ad¬ 
ditional strength operation. The effectful semantics for /et-binding is as follows 
(here a -A b abbreviates / : a b with arrow concatenation expressing compo¬ 
sition; [—] brackets are elided on types in morphisms for brevity): 

lrhe:t}=g:r^mt [T, s : th e' : If} = h : T x t ->• m t' (g) 
[r h let X = e in e' : f'] = r-^Kr x mt strength > m (rxt) mt' 

where (/, g) is the function pairing: Xx (/ x,g x), bind is the prefix version of 
Haskell’s (»=) :: Monad m => m a —> (a —> m b) —> m b operator and strength 
provides distributivity of x over m: 

strength : (a x to b) m (a x b) 
bind : (a -» mb) —> (m a mb) 

Whilst the do-notation provides a semantics for effectful let-binding embedded 
in Haskell, the translation is simplified by reusing Haskell’s scoping mechanism 
since, in Haskell, all monads are strong with a canonical strength: 

strength :: Monad m => (a, m b) —> m (a, b) 
strength (a, mb) = mb >= (A b —> return (a, b)) 

It is straightforwardly proved that this definition of strength satisfies the prop¬ 
erties of a strong monad (see [14] for these properties). The standard translation 
of do can be derived from (6) by inlining the above strength and simplifying 
according to the monad laws: 

r h e : mt r,x : t\~ e' : mt' 
r \- [do x 4- e; e'] : to t' = The >= (Xx —> e') : m t' 

This gives a translation using just the monad operations and Haskell’s scop¬ 
ing mechanism to define the semantics of multi-variable scopes for effectful let- 
binding. Thus the inputs to effectful computations are handled implicitly and so 
a do-block is an expression of type m a. 

Categorical semantics for contextual computations The dual of Moggi’s 
semantics interprets expressions in a coKleisli category, with denotations: 


[ad : h,... x n : t n b e : f] : c ([fi] x ... x [f„]) —> [f] 




for a comonad c. Uustalu and Vene gave the semantics of a context-dependent 
calculus in this form [8]. 

For a comonadic semantics, the input of an expression - the values of the free 
variables - thus have a comonadic product structure rather than just a product 
structure as in the monadic approach. Therefore, Haskell’s scoping mechanisms 
cannot be directly used since the variables local to a codo-block must have the 
same comonadic context and are therefore wrapped in a comonadic data type. 
The local environment of a codo-block is therefore handled manually in the 
desugaring of codo resulting in a more complicated translation than that of 
the do-notation. The desugaring of statements is equivalent to the semantics of 
/et-binding in Uustalu and Vene’s approach: 

[T h e : t] = g : c r —> t \T,x : t H e! : t'J = h : c(r x t) -» t' 

[-T b let X = e in e':i'] = cT extend{extract,g) > c (p x {./ 

The other parts of the desugaring manage projections from the (comonadic) en¬ 
vironment, simulating application and variable access in a comonadic semantics. 

5 Related Work and Conclusions 

Arrow notation In Haskell, various notions of computation can be encoded as 
a category structure, with additional arrow operations for constructing compu¬ 
tations and handling environments, defined by the Category and Arrow classes: 

class Category cat where class Category a => Arrow a where 

id :: cat x x arr :: (x —> y) —> a x y 

(o):: cat y z —» cat x y cat x z first:: a x y —► a {x, z) (y, z) 

A Category thus has a notion of composition and identity for its morphisms, 
which are modelled by the type cat x y. The Arrow class provides arr for 
promoting a Haskell function to a morphism and first transforms a morphism to 
take and return an extra parameter, used for threading an environment through 
a computation. Other arrow combinators can be derived from this minimal set. 

Every comonad defines a coKleisli category, whose morphisms have struc¬ 
tured input, where composition is defined as in Section 1. Furthermore, all coK¬ 
leisli categories in Haskell are arrows: 

data CoKleisli c x y = CoK {unCoK :: (c x —» y)} 
instance Comonad c =>■ Category ( CoKleisli c) where 
id = CoK extract 

{CoK g) o {CoK f) = CoK {g o {extend /)) 
instance Comonad c => Arrow {CoKleisli c) where 
arr k = CoK {k o extract) 

first {CoK f) = CoK {\x —> (/ {cmap fst x), extract {cmap snd a:))) 

where arr pre-composes a function with extract, and first is defined similarly to 
the handling of the local block environment in the desugaring of codo. 



The arrow notation simplifies programming with arrows [16,17], comprising: 
arrow formation (proc x — > e), arrow application (/ -< x) and binding {x <— e). 
Given the above coKleisli instances for Category and Arrow , comonadic opera¬ 
tions can be written in the arrow notation instead of using the codo-notation. 
For example, the original contours example can be written as follows: 

proc x —► do y <— CoK gauss2D -< x 
z <- CoK gauss2D -< y 
w «— retumA -< y — z 
CoK laplace2D < w 

The arrow notation here is not much more complicated than codo, requiring 
just the additional overhead of the arrow application operator -< and lifting of 
gauss2D and laplace2D by CoK. One difference is that the variables here have 
a non-comonadic type, i.e., Float rather than CArray (Int, Ini) Float. 

The arrow notation is however more cumbersome than codo when plumbing 
comonadic values, for example when using comonadic binary functions (of type 
c t —> c t' — > t"). The alternate definition of contours using minus becomes: 

proc x do y <— CoK gauss2D -< x 
z <- CoK gauss2D -< y 

w 4- CoK (Xv —> minus (fmap fst v) (fmap snd v)) -< (y, z) 
CoK laplace2D -< w 

where v:: c (y,z) must be deconstructed manually. Whilst minus can be inlined 
here and the code rewritten to the more elegant first example, this is only possible 
since minus applies extract to both arguments. For other comonadic operations, 
with more complex behaviour, this refactoring is not always possible. 

Comparing the two, arrow notation appears as powerful as codo-notation, 
in terms of the computations which can be expressed. Indeed, from a categor¬ 
ical perspective, both notations need only a comonad structure (i.e., coKleisli 
category) with no additional closed or monoidal structure (see Paterson’s dis¬ 
cussion [17, §2.1]). However, whilst arrow notation is almost as simple as codo 
for some purposes, the syntax is less natural for more complicated plumbing 
of comonadic values (as seen above). We argue that codo provides the most 
elegant and natural solution to programming with comonads, with a cleaner 
applicative-style. 

Other applications There are many interesting comonads which have not been 
explored here. For example, the semantics of the Lucid dataflow language are 
captured by an infinite stream comonad [4], which was used by Uustalu and 
Vene to define an interpreter for Lucid in Haskell. Using codo-notation, Lucid 
can be embedded directly into Haskell as an internal domain-specific language. 

Many comonadic data types are instances of the general concept of contain¬ 
ers. Containers comprise a set of shapes S and, for each shape s € S', a type of 
positions Ps, with the data type C a = ]U] sGS (-P.s —► a), i.e., a coproduct of func¬ 
tions from positions to values for each possible shape [18]. Ahman et al. recently 



showed that all directed containers (those with notions of sub-shape) are comon- 
ads, where positions are contexts and sub-shapes define accessibility between 
contexts for the definition of extend [11]. The labelled binary-tree example in Sec¬ 
tion 1 can be described as a directed-container comonad. The costate comonad 
can be generalised to cursored containers with type C a = Yl s es(P s a) x Ps. 

Whilst the codo-notation was developed here in Haskell, it could be applied 
in other languages with further benefits. For example, a codo-notation for ML 
could be used to abstract laziness using a delayed-computation comonad with 
data type C a = ()—»■ a, or defining lazy lists using the stream comonad. 

Concluding remarks Comonads essentially abstract boilerplate code for data 
structure traversals, allowing succinct definitions of local operations by abstract¬ 
ing their promotion to global operations. The codo-notation presented here sim¬ 
plifies programming with comonads. We hope this prompts the use of comonads 
as a design pattern and tool for abstraction, and promotes further exploration 
of comonads yielding new and interesting examples. 

Whilst the codo keyword is used in the notation here, some may prefer an al¬ 
ternate keyword as codo-notation is not exactly dual to do-notation (Section 4). 
For example, using context as the keyword provides more intuition about its 
use, akin to do, but causes more serious namespace pollution. 
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A Proof of shape preservation 


To prove shape preservation we first prove the following intermediate lemma: 

cmap g o extend f = extend (g o /) (7) 


cmap g o extend f 

= extend (g o extract) o extend f definition of cmap 
= extend (g o extract o extendf) [C3] 

= e3dend(gof) □ [C2] 

The proof of shape preservation (3) is then: 


shape o (extend f) 

= (cmap (const ()) o [extend f) 

= extend ((const ()) o /) 

= extend ((const ()) o extract) 

= (cmap (const ())) o (extend extract) 
= cmap (const ()) 

= shape 


definition of shape 

(7) 

(const x) of = (const x 

(7) 

[Cl] 

definition of shape 



